Field of the Invention
The invention relates to a test device for testing at least a portion of a virtual electronic control unit with a simulation environment in a simulator, having the virtual electronic control unit and the simulation environment, wherein the virtual electronic control unit comprises at least one software component with at least one external data interface, wherein the simulation environment comprises at least one data interface for at least indirect data exchange with the virtual electronic control unit.
Description of the Background Art
Nowadays non-virtual, which is to say “real,” control units are usually considered to be small computers with an I/O interface (I/O=input/output) that often are equipped with a real-time-capable operating system that allows even complex tasks, mostly feedback control tasks, to be implemented on the control unit. Control unit development is a core part of the technical development of large-scale equipment facilities such as are known from industrial practice. The use of control units in the automotive industry, in the aerospace industry, and in industrial production facilities is cited by way of example.
Testing of the mass produced control unit employed in the end product is the final point of multiple preceding development steps of a closed-loop or open-loop control to be implemented on the control unit, wherein these development steps usually are described with the so-called V-model or else V-cycle. Controller development, which is essential for functionality of many technical systems, starts off with the mathematical modeling of the control algorithm on a computer with a mathematical and graphical modeling environment, wherein the controller should be considered a part of the control unit. In addition, the environment of the control unit is also modeled mathematically, since the interaction of the controller on the control unit with the process to be controlled is of interest. In these functional mathematical considerations, simulation in real time generally is not necessary (offline simulation).
In the next step, the previously developed control algorithm is transferred by Rapid-Control-Prototyping to a powerful hardware unit, usually a hardware unit that is real-time-capable, which is connected to the actual physical process by suitable I/O interfaces, which is to say to a motor vehicle engine, for instance. Generally speaking, this real-time-capable hardware unit has nothing to do with the mass produced control unit that will later be employed; at issue here is proof of the basic functionality in practice of the previously developed control.
In another step, as part of automatic production code generation the control that is likely to actually be employed later in the mass produced control unit is implemented on the target processor. Accordingly, in this step, the target hardware approximates the mass produced control unit, but is not identical to the mass produced control unit. In another step, the mass produced control unit—which normally does not exist until a later development stage—is tested in the framework of a Hardware-in-the-Loop test (HIL). The mass produced control unit physically present in this step is connected by means of its physical control unit interface to a powerful simulator here. The simulator simulates the required variables of the mass produced control unit to be tested, and exchanges input and output variables with the mass produced control unit. The pins of the physical control unit interface of the mass produced control unit are connected to the simulator by a cable harness. In this way, it is possible to simulate all required variables of a motor vehicle engine—if applicable the entire motor vehicle with engine, drive train, chassis, and plant model—and to test the behavior of the mass produced control unit in interaction with the simulation environment in a risk-free manner.
The mass produced control unit tested within the framework of the HIL simulation is ultimately tested in the “real” target system, which is to say, for example, installed in a motor vehicle and tested in the real physical environment that was merely imitated in the simulation environment.
The above-outlined development process in controller development has stood the test of time extremely well. However, the development process involves the circumstance that the mass produced control unit is not incorporated until the very end of development, and thus also is not tested until the late development stages. Before the mass produced control unit is actually available, functionalities can only be tested at an abstract functional level with the indicated development process, which is to say practically only at the level of application software. A significant portion of the software components later employed on the mass produced control unit are not included in testing in early development stages. One of these software components is the runtime environment, for example, which mediates between the application software and the software layers close to the hardware. Examples of software layers close to the hardware include the operating system and platform-independent system software (system services, communication services, I/O hardware abstraction layer, etc.), and lastly, platform-dependent parts of the operating system and system software.
In order to include these extensive parts of the mass produced control unit in the development process early on, the aforementioned software components are—at least partly—reproduced as part of a so-called virtual electronic control unit and are simulated in a simulator (dSPACE Catalog 2012: “SystemDesk V-ECU Generation Module” and “dSPACE Offline Simulator”). In the simulator, the virtual electronic control unit interacts in all cases with the simulation environment that is likewise present in the simulator. The interaction takes place through the exchange of data through the at least one external data interface of a software component of the virtual electronic control unit and a data interface of the simulation environment. Which software components of the virtual electronic control unit provide an external data interface depends on which of the aforementioned software layers are represented in the virtual electronic control unit. If only the abstract application software is represented in the virtual electronic control unit, then the software components of the application software provide the external data interfaces to the simulation environment. In contrast, if the runtime environment is also a component of the virtual electronic control unit, then the external data interfaces are provided by their software components. If still lower software layers are represented, for example the operating system or system software components, then these software components provide the external data interface to the simulation environment.
It is evident that in each case the simulation environment must adapt to the external data interface of the software components of the virtual electronic control unit as a function of the software components reproduced in the virtual electronic control unit. Each change to the virtual electronic control unit that affects a software component with an external data interface also inevitably necessitates a change to the simulation environment and the data interface of the simulation environment, which is labor-intensive and introduces a source of errors in the development process. Another disadvantage is that the simulation environment adapted to a specific virtual electronic control unit as part of the HIL simulation—which is to say when the control unit is no longer present only in virtual form but is actually physically present—oftentimes cannot be used directly, since there is no provision of pin-related variables of the physical control unit at the data interface of the simulation environment that is necessary for such a use.